There is an increasing number of applications in which data is transferred between a transmitter and a receiver as a plurality of data streams over a single logical link. The data streams can be segmented at the transmitter into packets, each of which contains some data from the data streams. Usually, but not necessarily, each packet contains data from only one of the data streams. The packets are then transmitted independently over the link. When the packets are received at the receiver they are reassembled so as to re-form the data streams. Advantages of this system over conventional analogue techniques are that there is no need for a dedicated link or channel to be assigned to each of the data streams; that interference in transmission may affect only some of the packets, leaving some data streams unaffected; and that packets may be routed to the receiver over any available physical link and still combined properly to re-form the data streams even if the packets arrive out of order.
Each packet normally includes control data that allows the packet to be reassembled properly by the receiver. This may comprise data indicating the data stream whose data is included in the packet, and a serial number for the packet so that the packet can be combined in the correct order with others from that data stream. The control data can also comprise error-check data such as a checksum for allowing the receiver to verify that the packet has not been corrupted during transmission.
One application for the above technology is in the delivery of digital video signals to households via cable or satellite links. Digital video streams may be packetized and then broadcast to household receivers. A user of a receiver may then select one of the streams for viewing. The receiver can then reassemble that video stream from the received packets, convert it to a form suitable for input to the user's television and then output the resulting signal to the television. It has been proposed that such systems could offer additional features. These features include the storing of received streams for later viewing, and the displaying of program guides (lists of programs with transmission times) which could be assembled by the receiver from certain transmitted packets.
FIG. 1 shows the transport packet stream syntax specified in ITU-T standard H.222.0, equivalent to ISO/IEC standard 13818-1. (Further detail of the structure is available from the standard itself, the contents of which are incorporated herein by reference). FIG. 1 is equivalent to annex F.0.1 of the H.222 standard. The transport stream 1 comprises a stream of packets, each of which consists of 188 bytes. Each packet has a variable length header illustrated at 2 and a payload which occupies the remainder of the packet. The header has the following structure:
Number of bitsSignification8Synchronization byte1Transport error indicator1Payload unit start indicator1Transport priority13 Program identification (PID)2Transport scrambling control2Adaptation field control4Continuity counterVariableAdaptation field
The structure of the adaptation field is shown in more detail in FIG. 1.
Data representing video, audio, system information such as program guides and other user data streams can be carried as PES packets, which can be included in the payloads of the transport stream packets. The structure of a PES packet is shown in FIG. 2. FIG. 2 is equivalent to annex F.02 of the H.222 standard. Each PES packet comprises a 24 bit packet start code prefix, an 8 bit stream identification, 16 bits indicating the length of the PES packet, an optional variable length PES header and PES packet data of variable length.
FIG. 3 shows that the PES packets together form part of a program stream, whose structure is shown in FIG. 3. FIG. 3 is equivalent to annex F.0.7 of the H.222 standard.
In addition, section data can be carried in the packets. The section data can include information that is to be interpreted by the decoding unit. For example, section data may include:
1. data that is to be assembled by the receiving unit into a program guide indicating the programs that are to be provided on a channel;
2. data that is to be assembled into code that can be executed by an interpreter (an “o-code interpreter”) in the receiving unit; and/or
3. data that is to be assembled into decoding keys to allow the receiving unit to decrypt encoded data transmissions such as pay-per-view video.
The overall structure of an H.222 packet containing section data is summarized in FIG. 4, which shows schematically some important features of the packet. The packet comprises a header 5, an adaptation field 6 and a payload 7. The header includes a payload unit start bit 8 and a program identifier (PID) 9. The payload includes one or more sections 10 and, if the payload unit start bit is set, a pointer field 11 which indicates the offset x to the start of the first new section (the intervening bits of the packet may represent tail data of a preceding section). Each section includes information giving the length of that block, and periodically a section includes CRC (cyclic redundancy check) data for it, in order for the receiver to check that section has been correctly received.
A receiving unit can check that a contiguous group of blocks of data forming a section has been received correctly, by calculating a CRC value for the section once it has been received and comparing the calculated CRC value with the received CRC data or, for example, a preset value. If there is the required match then it is assumed that the data has been received correctly. If there is not the required match then the whole section as received is discarded. Retransmission of the section may then be requested, or the receiver may assume that the incorrectly received section has been lost and continue by receiving the next section. In one such checking method a counter is maintained at the receiver, with an initial value of −1. Every incoming byte is combined in turn with the value in the counter to create a new value. The 4 bytes of CRC data at the end of a section are of the values such that if they and the rest of the section have been correctly received then after those 4 bytes have been combined in turn with the counter the value of the counter will be zero. A final value in the counter that does not match zero indicates that data has been corrupted.
During the processing of a data stream it is often required that data packets be injected into the stream, regularly or irregularly. For example, it may be required to insert program guide or teletext information into a digital video transport stream. Conventionally, the insertion of these packets is performed in-line with the standard processing of the data stream, and it therefore puts additional load on the apparatus that performs that standard processing since that apparatus must periodically interrupt its normal operations and determine which additional packets are to be inserted. Furthermore, relying on the standard processing apparatus to insert the packets does not take advantage of the fact that some data packets may have to be inserted repeatedly, at fixed or different intervals.
There is therefore a need for an improved means of inserting data packets into a data stream.